A multitude of different communication terminals and devices are available today that are capable of packet-based multimedia communication using IP (Internet Protocol), such as fixed or mobile computers and telephones. Multimedia services typically entail transmission of media in different formats and combinations over IP networks. For example, an IP-enabled mobile terminal may exchange audio information as well as visual information with another IP-enabled mobile terminal, or may download media in any format from a content server.
A service and service-delivery control architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions, commonly referred to as the IMS network. Thus, an IMS network can be used to initiate and control multimedia sessions for IMS-enabled terminals connected to different access networks, regardless of access technology. Although conceived primarily to enable multimedia services for mobile IP terminals, the IMS concept can also be used by fixed IP terminals. In ETSI (European Telecommunications Standards Institute), a working group called TISPAN (Telecom and Internet Services and Protocols for Advanced Networks) is currently working with the adoption of IMS in fixed networks.
Multimedia sessions are handled by specific session control nodes in the IMS network, typically including the nodes P-CSCF (Proxy Call Session Control Function), S-CSCF (Serving Call Session Control Function), and I-CSCF (Interrogating Call Session Control Function). An IMS network may also include various application servers for enabling various multimedia services, and a database node HSS (Home Subscriber Server) for storing subscriber and authentication data.
The signalling protocol called “SIP” (Session Initiation Protocol) is typically used for signalling messages during the setup of multimedia sessions in IMS networks. Standard SIP messages can thus be used by IP terminals or devices for establishing multimedia sessions. For example, a terminal can send an SIP message called “SIP INVITE” to initiate a session with another party in a session set-up procedure, e.g. when a multimedia application has been invoked in the terminal.
In SIP, an additional protocol called “SDP” (Session Description Protocol) is used for describing and specifying a multimedia session, and an SDP message can be embedded as a self-contained body within SIP messages. SDP messages are generally used to provide information on device capabilities and media properties, in order to specify and negotiate session parameters for multimedia sessions, as is well-known in the art. The term “session parameters” is used here to represent any device capabilities, media properties and address information necessary to establish a session. The above-mentioned SIP INVITE message and its common response message “SIP 200 OK” typically include an embedded SDP message with information on one or more codecs (coders/decoders) as well as other communication parameters needed for a session, such as an IP address and a port number.
According to 3GPP, a terminal must have an SIM (Subscriber Identity Module) application valid for IMS, generally referred to as “ISIM” (IMS SIM), in order to provide necessary authentication and subscriber data when registering with an IMS network. An ISIM stores an IMS Private Identity “IMPI” and at least one IMS Public Identity “IMPU”, which are both known to the IMS network. IMPI is used for authentication and each IMPU is associated with an IMS service profile, typically tied to a user.
It is also desirable to provide IMS-based services for different IP terminals connected to a private network such as a residential or office network, generally referred to as a home network, home LAN (Local Area Network) or local LAN. In this description, the generic term “home network” is used for any such networks, and the term “home device” is used for any IP terminal within the home network.
A home network typically comprises different types of home devices including, e.g., fixed and wireless telephones, computers, media players, servers and television sets. In order to provide IMS services to non-IMS enabled home devices in a home network, a multimedia gateway referred to as a “Home IMS Gateway, HIGA” has been defined that can act as an IMS enabled terminal to access IMS services on behalf of any home device in the home network.
Among other things, the HIGA includes a “Back-to-Back User Agent” (B2BUA) acting basically as a bridge for communications between non-IMS enabled home devices and the IMS network. The B2BUA is equipped with an ISIM application and handles IMS signalling with the IMS network on behalf of the home devices. For example, if a home device sends an SIP REGISTER message containing an SIP identity but no IMS identity, the B2BUA in HIGA will translate the message into an IMS valid REGISTER message containing both an IMPI and an IMPU, according to regular IMS procedures.
In FIG. 1, a home network 100 is shown comprising a plurality of different home devices in a family residence or an office. As illustrated here, these devices include a wireless telephone, a fixed telephone, a TV set, a PC (Personal Computer) and a server. The home network 100 also includes a conventional residential gateway RGW 102 connected to an external access network 104 to provide an external communication link for the devices in network 100. The RGW 104 typically includes an NAT (Network Address Translation) function and a local DHCP (Dynamic Host Configuration Protocol) server providing local IP addresses to the devices valid only within the home network, as is well-known in the art.
The home network 100 further includes an HIGA 106 providing a connection to an IMS network 108 in which an HSS 110 is shown. The HIGA 106 is equipped with suitable interfaces towards the different devices in network 100, using device-adapted protocols. In practice, the HIGA 106 may be physically integrated in the RGW 102 although it is logically considered as an individual functional unit in this description.
In HIGA 106, identity information 112 associated with a profile is stored for each user in network 100, typically the above-mentioned IMPU, valid for accessing IMS network 108 where the same identity information is stored as subscriber information 114 in HSS 110, as indicated in the figure. When a user generally logs on to an IMS network via a specific device, that device's IP address is associated to the users IMPU. Thus, each home device in network 100 has been assigned a local identity that can be associated with a specific IMS identity when a user is logged on to that specific device. WO 2006/045706 outlines how home devices in a home network can obtain IMS services by means of an HIGA using different combinations of IMPI and IMPU.
When a home device in network 100 sends a request for an IMS service to HIGA 106, using a protocol within its capability, HIGA 106 identifies the device by means of its local identity (e.g. the local IP address of the device) and typically retrieves the corresponding IMS identity 112 of the device itself or of the user logged on to that device. Then, HIGA 106 translates the service request into a valid IMS request (e.g. SIP INVITE) on behalf of the device, to set up a session for the device by communicating suitable SIP messages with the IMS network 108, accordingly. In a similar manner, an incoming request for an IMS session with one of the home devices can be set up by HIGA 106 using an IMS identity 112 associated with the device. In either case, the session is routed from/to the device over the RGW 102 to communicate media over the access network 104, as indicated in the figure.
UPnP (Universal Plug-and-Play) is an architecture developed in a multi-vendor collaboration referred to as the UPnP Forum, for establishing standard device protocols for the communication between IP devices in a home network. UPnP thus provides peer-to-peer connectivity between devices in a home network for different access technologies, operating systems, programming languages, format standards and communication protocols used by the devices. Further, UPnP supports a process referred to as “discovery” (or “pairing”) in which a device can dynamically join a home network, obtain a local IP address, announce its name and IP address, and exchange capabilities with other home devices. The UPnP Forum is currently in the process of defining an architecture for enabling remote access where remote UPnP devices located outside the private network can communicate media with home devices within the home network.
FIG. 1 further illustrates that a home device 100a moves outside the home network 100 to become a remote device 100a′. The remote device 100a′ then sends an INVITE message to the HIGA 106 over the IMS network 108 to initiate media communication with one of the home devices in network 100, requiring that the remote device has a valid IMS identity in order to access the IMS network. In WO 2006/079891 (Nokia), a solution is described for setting up a VPN (Virtual Private Network) tunnel as a data/media transport channel for remote UPnP access, e.g. using IPSec (IP Security).
In order to access a home device remotely, the remote device must have gained knowledge of the home device somehow in a discovery process. The remote device may have taken part in a regular discovery process recently while being located inside the home network 100, typically involving the exchange of certain discovery messages according to a protocol called SSDP (Simple Session Discovery Protocol). If this is not the case, however, such as when the remote device has in fact never been inside the network at all, it is necessary to exchange the discovery messages remotely.
FIG. 2 illustrates a possible logic structure in a remote device 200 and a residential gateway 202 of a home network for enabling remote access to home devices in the network (not shown). A Remote Access Client RAC 200a has been configured in the remote device 200 and a corresponding Remote Access Server RAS 202a has been configured in the residential gateway 202, which can be done preferably when both are present in the home network since RAC 200a and RAS 202a should be configured with matching profiles.
The remote access client 200a comprises a Remote Access Discovery Agent RADA 200b, and the remote access server 202a comprises a corresponding Remote Access Discovery Agent RADA 202b, configured to exchange discovery messages between the home network and the remote device. The remote access client 200a further comprises a Remote Access Transport Agent RATA 200c and the remote access server 202a comprises a corresponding Remote Access Transport Agent RATA 202c, configured to establish a transport channel for media between the remote device and the remote access server 202a. The RADA function may alternatively be referred to as a “UPnP proxy”, and the RATA function may alternatively be referred to as a “connectivity client”.
The configuration of RATA 200c, 202c is typically adapted to the characteristics of the used transport channel. When dynamic IP address assignments are used for residential gateways, the well-known solution of dynamic DNS (Domain Name System) can be used to resolve IP addresses of the residential gateway 202.
Additionally, the RADAs 200b, 202b may apply filters or the like to restrict the visibility of the home devices and/or services for the remote device, or vice-versa. Each RADA 200b, 202b may comprise an SSDP Proxy to aggregate information on home devices and services, and a Discovery Agent adapted to synchronize the remote access client 200a and the remote access server 202a. 
It is well known that different types of services involving the communication of media have different requirements with respect to the rate and/or latency for the data transport, in order to provide satisfactory results at the receiving end. For example, a conversational service involving real-time communication of voice or video tolerates only very short delays. Further, a streaming service involving the transfer of large amounts of data to be played out simultaneously at the receiving party requires that a certain data rate or bandwidth (sometimes referred to as “throughput”) is maintained during the session to avoid interruptions in the play-out, and so forth. Different levels or classes for QoS (Quality of Service) are therefore used of which, e.g., “real-time” guarantees low latency, “streaming” guarantees a certain bandwidth, and “best effort” has no guarantees for latency nor bandwidth whatsoever.
FIG. 3 illustrates schematically an architecture for the management of QoS in a fixed network for IMS sessions generally, as specified by TISPAN. A communication terminal referred to as user equipment 300 is attached to a fixed access node 302 in a fixed network. A layer 2 link connects the access node 302 to a suitable layer 2 termination point L2T 304 that constitutes an IP edge in the transition between the layer 2 communication and IP communication in layer 3. L2T 304 is in turn further connected to a gateway for communication with other networks, generally referred to as the “Border Gateway Function BGF” 306, in which an NAT function is typically implemented.
According to TISPAN, the control/management of QoS for IMS sessions is handled by a function called “Resource and Admission Control Subsystem RACS” 308 adapted to establish the QoS for each session which is then enforced at L2T 304 by a “Resource Control Enforcement Function RCEF” 310. RACS 308 is also generally responsible for policy control, resource reservation and admission control for IMS sessions, typically depending on the user. When an IMS session is established by an IMS network 312, e.g. using a P-CSCF node 312a for session control, the required session parameters or media properties are defined in SDP messages as described above, which the P-CSCF node 312a maps into QoS request information to be sent to RACS 308 and enforced by RCEF 310. Any address translation needed for the session in the network is also established in BGF 306 via RACS 308. The current scope of RACS generally covers the access network and the interconnection between different core networks.
However, the problem of providing a suitable or proper Quality of Service QoS for media sessions during remote access to a home network has not yet been addressed. When a remote device accesses a device in a home network to execute a multimedia session, the best effort type of QoS will only be obtained for the session since no QoS enforcement function is present, even though the service used may require a QoS level with higher demands.